FIG. 1 is a block diagram of prior art system 100. System 100 includes client 110 and service-oriented architecture 120. Client 110 may comprise a Web browser to access services provided by service-oriented architecture 120 via HyperText Transport Protocol (HTTP) communication.
For example, a user may manipulate a user interface of client 110 to input an instruction (e.g., update inventory). Client 110, in response, may transmit a corresponding HTTP service request to service-oriented architecture 120 as illustrated. Service-oriented architecture 120 conducts any processing required by the request (e.g., updating a list of inventory) and, after completing the processing, provides a response to client 110.
Client 110 does not receive any indication from service-oriented architecture 120 during the above-mentioned processing. Accordingly, after inputting the instruction and before receiving the response, the user is left to wonder whether any processing is occurring as a result of the instruction, whether service-oriented architecture 120 is non-responsive, or whether a network error has occurred between client 110 and service-oriented architecture 120. Service requests which require lengthy processing exacerbate this dilemma.
Due to the request/response nature of HTTP, the foregoing cannot be addressed simply by programming service-oriented architecture 120 to send some sort of progress indicator to client 110. Accordingly, what is needed is a system to provide meaningful progress information to a client of a service-oriented architecture.